What should we be looking at in the profiler? I will be honest and admit that for larger performance concerns outside of time spent, these finer features of the debugger are lost on me, and it seems like the heap is actually larger now overall. I'd be fine with the easiest to understand guide you are aware of.

Are you aware of the code/known issue/etc for all 3 of these libraries and can you link them? One of them being a leak wouldn't be a surprise, but all 3 is a bit wild. What's the likelihood that these global listeners aren't simply reused for all 3 once registered? Or that its memory that hasn't been gc'd yet? seems you accounted for this with manual gc in the profiler.

I am sorry, I should have been more precise in my original description.

What you should be looking at in the profiler (I have attached some screenshots of the before/after in the spoiler sections above) is mainly the green line, which represents the number of DOM nodes curently held in memory. Though The orange line (listeners currently in memory) in most cases perfectly correlates to that.
The Blue line in the above screenshots are plain "JS Heap", meaning pure javascript objects like strings, objects etc held in memory. That one is rapidly changing just from running the pixi event loop and is not a useful measurement here.

and it seems like the heap is actually larger now overall

If by that you mean plain JS heap, that one is very volatile and just by running the event loop, some "garbage" will collect, be mainly very shortly lived and then be collected. I have attached screenshot of the memory profile over a 23.5s window. You should see some blue spikes that reset to (mostly) the same low as before.

Screenshot of the plain JS heap over time

Reason for the periodical increase is the pixi/foundry render loop, which allocates some objects, maybe strings, buffers, etc during the rendering of a frame. The drop part of the spike is when the garbage collector kicks in and all the objects that are not referenced anymore are collected.
Now that I look at this in more detail, there might even be an issue with memory management in this core render loop somehow ("low" parts are ever increasing, even after a full garbage collection cycle), but that almost certainly has nothing to do with the pf2e system.

A more detailed analysis of the profile and testing

Lets look a the NPC sheet again. I'll create a new profile and concentrate on the important parts and provide some more details and actual values that are not available just looking at the screenshot. This is how I tested it (fresh reload not visible in the video)

before:
https://github.com/user-attachments/assets/c251c1af-496d-42d2-99de-575901ce07cb
Currently, after opening, then closing the NPC sheet, the number of DOM Nodes, and event listeners kept in memory is ever increasing. From 12,971 at the beginning to 18,767 at the end after a full garbage collecction.

after:
https://github.com/user-attachments/assets/9f88f075-d010-469e-96c6-1852e8288046
These tests were done with the codebase from this PR. In this case, the node count initially increases from 10,443 to 11,907 after closing the npc sheet and GC, but then after each opening, closing, GC cycle, the node count goes from 11,907 up to 14,148 an down again to 11,907 exactly, whithout a single node (or event listener) remaining in memory.

The important part here really is not how much memory is currently in use, how many nodes exactly are being allocated on a fresh reload etc. The important part here is that after opening, then closing a sheet, progressing in the encounter tracker etc, the node and listener count drops to exactly the value as before the operation. Everything else means some memory is being retained forever, ever increasing when of of these operations is being performed. (memory leak)

Regarding the libraries

Are you aware of the code/known issue/etc for all 3 of these libraries and can you link them?

There is no issue at all in the Sortable Library. The tagify Libray has some form of broken auto-cleanup which might warrant an issue or PR on that repository. But skimming over the documentation I would still go as far as to say they behave as intended. Tooltipster is slightly more complicated, but we'll get to that. Lets look at the libraries:

Sortable
Sortable.js keeps a reference of all active sortable instances in a local variable on module level, so instances that are created will never go out of scope (meaning there will always be a reference to that instance starting with the root GC node). The line in question.
The destroy function cleans up these references, making the sortable instance eligible for gargabe collection again.
I can find no reference either in the documentation or code that would suggest that some form of auto cleanup is intended when the DOM node sortable is registered for has become detached.

What's the likelihood that these global listeners aren't simply reused for all 3 once registered?
They are not reused, it's not a question of likelyh

Tagify
At least this line creates a reference by creating a timer (setInterval) which continues running until the interval is manually destroyed. The callback for this interval closes of the "this" variable, keeping it alive indefinitely. The check you see in the second code link (destroying the tagify instance if parentNode is not in the DOM anymore) is never triggered, since the direct parent of the tagify element is alwasys available. When replacing the HTML of the item sheet for example, only the root content node is actually not connected to the dom / has no parent anymore. All child elements are still connected in this detached DOM tree.
To make this library more resilient, the check could be changed to check if a this.DOM.originalInput.closest('body') evaluates to a truthy value... But it is also never documented anywhere that I can find that Tagify has this auto cleanup behavior, so I would argue manually calling destroy when the tagify instance is not needed anymore is the intended behavior of this library.

Tooltipster
I will not repeat the same analysis of what keeps references where for the tooltipster jQuery plugin, mainly because I'm unfamiliar with the jQuery plugin architecture... Fact is however that the situation with cleanup for tooltipster is a bit more complicated. It too provides a sort of destroy method by calling $(element).tooltipster('destroy'), the only issue being that this has to be called before the element tooltipster has been used on is removed from the dom. Reason for that is that in normal cirumstances, removal or replacement of the HTML is done by jQuery via containerElement.html(newHtml) or containerElement.replace(newContainerElement). Both function triger some sort of jQuery cleanup, removing data attributes set by jQuery if I understand correctly. This also removes the tooltipster-ns data attribute that tooltipster itself uses to verify that the instance is still active, throwing an error if that is not the case. Some global references to this tooltipster instance remain however if the element is removed by jQuery, leading to this unfortunate situation of having to destroy tooltipster before it is actually removed from the DOM.

Finally:

Or that its memory that hasn't been gc'd yet? seems you accounted for this with manual gc in the profiler.

You already noticed, but just to clarify that part or my method a bit more. Yes, that is what the manual GC step (brush or trashcan icon in the performance profiler dev tools tab next to the memory checkbox) is used for. This triggeres a full Garbage collection major cycle (or apparently even two full cycles?). This means that both short lived and long lived objects are iterated over, removing ALL memory that is no longer referenced from the root GC node.

I hope I could answer at least some of your questions or concerns. Please do ask further question If something is still unclear :)